feat(engine)!: add TakeFromBucket instruction + wallet multiple transfers - #1614

Reviewing files that changed from the base of the PR and between e1daa17 and 1e66877.

• applications/tari_walletd/src/handlers/accounts.rs (2 hunks)
• applications/tari_walletd/web_ui/src/services/api/hooks/useAccounts.ts (1 hunks)
• bindings/package.json (1 hunks)
• bindings/src/types/Instruction.ts (1 hunks)
• bindings/src/types/tari-indexer-client/IndexerGetIdentityResponse.ts (1 hunks)
• bindings/src/types/wallet-daemon-client/StealthTransfer.ts (1 hunks)
• bindings/src/types/wallet-daemon-client/StealthTransferRequest.ts (1 hunks)
• bindings/src/wallet-daemon-client.ts (1 hunks)
• clients/javascript/wallet_daemon_client/package.json (1 hunks)
• clients/wallet_daemon_client/src/types.rs (1 hunks)
• crates/engine/src/runtime/impl.rs (3 hunks)
• crates/engine/src/runtime/mod.rs (1 hunks)
• crates/engine/src/runtime/working_state.rs (1 hunks)
• crates/engine/src/transaction/processor.rs (2 hunks)
• crates/engine/tests/account.rs (1 hunks)
• crates/engine/tests/test.rs (1 hunks)
• crates/p2p/proto/transaction.proto (2 hunks)
• crates/p2p/src/conversions/transaction.rs (2 hunks)
• crates/template_lib/src/component/instance.rs (1 hunks)
• crates/template_lib/src/resource/builder/fungible.rs (1 hunks)
• crates/template_test_tooling/src/read_only_state_store.rs (2 hunks)
• crates/template_test_tooling/templates/faucet/src/lib.rs (1 hunks)
• crates/transaction/src/builder/mod.rs (1 hunks)
• crates/transaction/src/v1/instruction.rs (2 hunks)
• crates/transaction/src/v1/transaction.rs (2 hunks)
• crates/wallet/sdk/src/apis/stealth_outputs.rs (3 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/api.rs (13 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/error.rs (1 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/mod.rs (1 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/params.rs (1 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/types.rs (1 hunks)
• integration_tests/src/wallet_daemon_client.rs (2 hunks)

• GitHub Check: check nightly
• GitHub Check: test
• GitHub Check: machete
• GitHub Check: clippy
• GitHub Check: check stable
• GitHub Check: fmt

bindings/src/types/tari-indexer-client/IndexerGetIdentityResponse.ts (1)

7-7: Array notation is consistent across ts-rs generated files—no action needed.

Verification confirms that Array<string> notation is systematically used across all ts-rs generated type files in the bindings directory (6 instances found across multiple directories), with no instances of string[] notation. This indicates the change is the expected output of the ts-rs code generator, not a manual stylistic edit. The file is correctly generated and consistent with the codebase.

crates/template_test_tooling/src/read_only_state_store.rs (1)

90-94: LGTM: Improved API design.

The signature change from FnMut(Substate) to FnMut(&SubstateId, &Substate) is an improvement that provides more context to callers while avoiding unnecessary cloning during iteration. The implementation correctly forwards both parameters to the closure.

clients/wallet_daemon_client/src/types.rs (2)

1070-1078: LGTM! Well-structured type definition.

The StealthTransfer struct clearly encapsulates per-transfer data with appropriate field types. The skip_serializing_if attribute on output_memo is a good optimization for optional fields.

---

1064-1064: No changes needed—empty transfers are already validated.

The code properly validates that the transfers vector is non-empty. The StealthTransferParams::validate() function checks if self.outputs.is_empty() and returns an error with the message "At least one output must be specified" if no outputs are provided. This validation is called in the handler before processing the request.

crates/template_test_tooling/templates/faucet/src/lib.rs (2)

38-40: LGTM! Clean delegation pattern.

The refactor maintains backward compatibility while enabling the new optional address allocation functionality.

---

42-56: LGTM! Well-structured API extension.

The new mint_with_opts function correctly extends the faucet API to support optional address allocation without breaking existing consumers.

crates/template_lib/src/resource/builder/fungible.rs (1)

120-122: LGTM! Appropriate builder pattern update.

Changing to consume self by value and delegating to the optional variant is a clean refactor that maintains the fluent builder API.

crates/template_lib/src/component/instance.rs (2)

34-36: LGTM! Clean builder pattern refactor.

The change to consume self and delegate to the optional variant maintains the fluent builder API while centralizing the allocation logic.

---

39-45: LGTM! Excellent defensive implementation.

The assertion at Line 41 prevents accidental overwriting of an existing allocation, providing clear feedback if the builder is misconfigured. The None case safely no-ops, making this pattern robust.

crates/wallet/sdk/src/apis/stealth_transfer/error.rs (1)

18-44: LGTM: coherent error surface.

Enum is well-structured and composes upstream APIs cleanly; IsNotFoundError impl matches store semantics.

applications/tari_walletd/web_ui/src/services/api/hooks/useAccounts.ts (1)

118-130: <!-- [scratchpad_start]
[task verification_1/1 check_request_contract_3/3]
Status: Verification complete. All findings gathered.
[observations]

• StealthTransferRequest struct (line 1060-1068):
  • owner_account: ComponentAddressOrName ✓
  • transfers: Vec ✓
  • Matches review expectation
• StealthTransfer struct (1072-1078):
  • destination_address: OotleAddress ✓
  • blinded_output_amount: Amount ✗ (NOT number - this is the issue!)
  • revealed_output_amount: Amount ✗ (NOT number - this is the issue!)
  • output_memo: Option ✓
• Amount type: exports as string | number in TypeScript per previous search
• Current implementation (lines 153-167):
  • Uses "owner_account" field name correctly ✓
  • Passes params.amount as number directly to Amount fields
  • No type conversion to Amount - values just cast implicitly
• TransferParams.amount typed as number (line 120), should be Amount

[analysis]
CORRECT ISSUES IDENTIFIED:

1. TransferParams.amount is number but should be Amount to prevent precision loss
2. The implementation in useAccounts.ts passes number values to Amount-typed fields
3. Amount supports string | number in TS, but proper typing prevents runtime errors
4. The owner_account field name is ALREADY CORRECT (not a bug in current code)

VERIFIED FACTS:

• Server expects owner_account (confirmed ✓)
• Server expects transfers array with these exact fields (confirmed ✓)
• Amount type should be used for blinded_output_amount and revealed_output_amount (confirmed ✓)
• Current code already uses owner_account correctly at line 154 (already fixed or was never wrong)

[done]
Ready to generate rewritten review comment. The review comment is mostly correct but needs refinement:

• The field name concern (owner_account vs account) is ALREADY addressed in the implementation
• The Amount typing concern is the main actionable issue remaining
  </scratchpad_end] -->

Tighten amount typing from number to Amount; server contract verified.

The code correctly uses owner_account and the transfers array structure matches the server contract. However, TransferParams.amount should use the Amount type instead of number to prevent precision loss for large values:

-  amount: number;
+  amount: Amount; // from @tari-project/typescript-bindings

The blinded_output_amount and revealed_output_amount fields in the transfers array (lines 160–161) are correctly mapped to Amount types server-side; using Amount at the parameter level ensures type safety and consistency.

crates/wallet/sdk/src/apis/stealth_transfer/types.rs (1)

34-39: LGTM!

The struct is well-designed with appropriate derives and a lifetime parameter for the memo reference.

crates/transaction/src/v1/transaction.rs (2)

191-191: LGTM!

The weight of 1 for TakeFromBucket is consistent with other simple workspace operations like AssertBucketContains and ClaimValidatorFees.

---

199-202: Baseline weight added for stealth transfers.

The addition of a fixed baseline weight of 100 for stealth transfer statements reflects the cryptographic overhead of these operations. This is a reasonable approach given the computational cost of validating stealth proofs.

bindings/src/wallet-daemon-client.ts (1)

35-35: LGTM!

The export of StealthTransfer is correctly placed and consistent with the existing export structure.

crates/transaction/src/v1/instruction.rs (2)

75-79: LGTM!

The TakeFromBucket instruction variant is well-structured with appropriate fields for specifying the source bucket, amount to take, and destination bucket.

---

190-200: LGTM!

The Display implementation for TakeFromBucket properly formats all three fields, maintaining consistency with other instruction Display implementations.

crates/engine/src/runtime/working_state.rs (1)

399-406: Improved dangling bucket validation.

The validation now correctly counts only non-zero buckets as dangling, rather than all buckets. This is more accurate since empty buckets don't represent leaked resources and shouldn't cause transaction failures.

crates/engine/src/runtime/mod.rs (1)

192-192: New RuntimeInterface method added.

The put_on_workspace method extends the runtime API to support placing values directly on the workspace by ID. This is a breaking change to the RuntimeInterface trait, but is necessary to support the new TakeFromBucket instruction flow.

crates/engine/tests/account.rs (1)

281-331: LGTM! Comprehensive test for TakeFromBucket.

The test effectively covers:

• Creating a faucet and taking free coins
• Splitting a bucket into two parts using TakeFromBucket
• Testing the edge case where the source bucket is fully drained (line 302 comment)
• Verifying final account balances

The test validates that empty buckets don't cause dangling bucket errors, which aligns with the working_state.rs validation changes.

bindings/src/types/Instruction.ts (1)

24-33: TakeFromBucket variant wired correctly.

Nice to see the bindings keeping pace with the engine changes so clients can emit the new instruction without hand-written glue. Nothing further from my side.

bindings/src/types/wallet-daemon-client/StealthTransferRequest.ts (1)

7-13: Aggregated transfers shape looks good.

Thanks for moving the request over to the transfers array; this matches the backend refactor and keeps the types tidy.

bindings/src/types/wallet-daemon-client/StealthTransfer.ts (1)

1-11: Handshake between Rust and TS stays aligned.

Appreciate the dedicated StealthTransfer type; makes the client payload much clearer.

crates/engine/src/transaction/processor.rs (1)

319-336: Runtime hook for TakeFromBucket looks solid.

The workspace fetch + bucket take + reinsert flow mirrors the existing engine patterns, so I don’t see any gaps here.

crates/engine/src/runtime/impl.rs (2)

1950-1955: Nice touch on state.new_bucket_id().

Switching to the helper keeps bucket allocation consistent with the other call sites.

---

2697-2705: Handy put_on_workspace helper.

Centralising the insert logic with validation makes the new instruction cleaner.

crates/transaction/src/builder/mod.rs (1)

259-272: Builder API addition fits right in.

This will make composing multi-output flows far less awkward; thanks for the ergonomic win.

applications/tari_walletd/src/handlers/accounts.rs (2)

26-33: Wallet-side refactor matches the new SDK params.

Mapping the request transfers straight into TransferOutput keeps the handler clean and future-proof.

---

971-986: End-to-end payload assembly still lines up.

The new outputs collection is passed straight through to the SDK, so the daemon remains in lockstep with the client types.

crates/wallet/sdk/src/apis/stealth_outputs.rs (1)

44-44: LGTM! Type rename and borrowing optimization.

The refactor from OutputToCreate to StealthOutputToCreate makes the type more specific and self-documenting. The borrowing change on line 680 (&output.owner_address instead of moving) is a good optimization that avoids unnecessary clones while maintaining safety through the lifetime parameter 'a.

Also applies to: 667-667, 680-680

crates/p2p/src/conversions/transaction.rs (2)

236-244: LGTM! Proper error handling and validation.

The proto-to-internal conversion correctly:

• Validates required input_bucket field with descriptive error message
• Handles optional amount with sensible default
• Protects against output_bucket overflow with proper context

Follows the established pattern from other instructions like AssertBucketContains.

---

388-400: LGTM! Consistent serialization implementation.

The internal-to-proto conversion properly wraps all fields and follows the same structure as other instructions in this file.

crates/p2p/proto/transaction.proto (1)

35-40: Breaking change properly documented.

The field number renumbering for existing instruction variants (lines 35-39) and the new TakeFromBucket message definition (lines 65-69) constitute a breaking protocol change. This is acknowledged in the PR description with "Requires deletion of the data directory."

The new message structure correctly aligns with the conversion implementation in crates/p2p/src/conversions/transaction.rs.

Also applies to: 65-69

integration_tests/src/wallet_daemon_client.rs (1)

126-131: LGTM! Test correctly updated for multi-transfer API.

The refactoring from flat transfer fields to a transfers collection properly supports the new capability of sending to multiple recipients in a single transaction. The test correctly creates a single-element vector to match the new API signature.

crates/wallet/sdk/src/apis/stealth_transfer/api.rs (6)

319-328: LGTM! Pre-determining account creation needs is efficient.

This loop gathers which destination accounts need to be created before transaction construction. This approach allows the transaction builder to make informed decisions about whether to create accounts or deposit to existing ones.

The use of HashSet for accounts_to_create provides O(1) lookup during transaction building.

---

589-676: Well-structured account existence check with proper network fallback.

The function correctly handles multiple scenarios:

1. ✅ Early exit for stealth-only transfers (no revealed funds)
2. ✅ Local account check with on-chain confirmation validation
3. ✅ Network lookup as fallback
4. ✅ Proper vault substate inclusion for existing accounts

The logic properly adds both the account and vault (if exists) to substate_inputs, ensuring the transaction has required inputs for deposit operations.

---

507-516: Output ordering is critical for change detection logic.

The chaining order (explicit outputs → change output → filter) is important because line 522 relies on .last() to access the change output. This works correctly because:

1. change_output is chained after all explicit outputs
2. The filter preserves order
3. If change amount is positive, it will be the last element

However, this implicit ordering dependency is subtle and could be fragile.

Consider adding an assertion or comment documenting this ordering requirement:

// NOTE: change_output must be chained last because we access it via .last() below (line 522)
outputs: params
    .outputs
    .iter()
    .map(Into::into)
    .chain(change_output)
    .filter(|o| o.amount.is_positive()),

---

742-764: Transaction builder correctly handles conditional account creation.

The logic properly:

1. ✅ Iterates over outputs with index for unique bucket naming
2. ✅ Skips outputs with no revealed amount
3. ✅ Uses take_from_bucket to split the output bucket by exact revealed amount
4. ✅ Creates account with bucket for new accounts (using accounts_to_create set)
5. ✅ Deposits to existing accounts otherwise

The use of sub_bucket_name with index ensures unique workspace keys.

---

359-364: LGTM! Consistent with API refactoring.

The change to StealthOutputToCreate with owner_address.clone() is necessary because the type now uses borrowing semantics (as seen in stealth_outputs.rs). The clone here is unavoidable since we need to hold the value across iterations.

Also applies to: 491-495

---

692-699: Good addition of network parameter for transaction building.

The network parameter (line 692) is properly used on line 704 to set the transaction network via .for_network(network.as_byte()). The accounts_to_create parameter enables the conditional account creation logic.

Reviewing files that changed from the base of the PR and between 1e66877 and f9cc889.

• Cargo.lock is excluded by !**/*.lock

• Cargo.toml (1 hunks)
• applications/tari_walletd/src/handlers/accounts.rs (2 hunks)
• applications/tari_walletd/web_ui/src/services/api/hooks/useAccounts.ts (1 hunks)
• bindings/package.json (1 hunks)
• bindings/src/types/Instruction.ts (1 hunks)
• bindings/src/types/tari-indexer-client/IndexerGetIdentityResponse.ts (1 hunks)
• bindings/src/types/wallet-daemon-client/StealthTransfer.ts (1 hunks)
• bindings/src/types/wallet-daemon-client/StealthTransferRequest.ts (1 hunks)
• bindings/src/wallet-daemon-client.ts (1 hunks)
• clients/javascript/wallet_daemon_client/package.json (1 hunks)
• clients/wallet_daemon_client/src/types.rs (1 hunks)
• crates/engine/src/runtime/impl.rs (3 hunks)
• crates/engine/src/runtime/mod.rs (1 hunks)
• crates/engine/src/runtime/working_state.rs (1 hunks)
• crates/engine/src/transaction/processor.rs (2 hunks)
• crates/engine/tests/account.rs (1 hunks)
• crates/engine/tests/test.rs (1 hunks)
• crates/p2p/proto/transaction.proto (2 hunks)
• crates/p2p/src/conversions/transaction.rs (2 hunks)
• crates/template_lib/src/component/instance.rs (1 hunks)
• crates/template_lib/src/resource/builder/confidential.rs (1 hunks)
• crates/template_lib/src/resource/builder/fungible.rs (1 hunks)
• crates/template_lib/src/resource/builder/non_fungible.rs (1 hunks)
• crates/template_lib/src/resource/builder/stealth.rs (1 hunks)
• crates/template_test_tooling/src/read_only_state_store.rs (2 hunks)
• crates/template_test_tooling/templates/faucet/src/lib.rs (1 hunks)
• crates/transaction/src/builder/mod.rs (1 hunks)
• crates/transaction/src/v1/instruction.rs (2 hunks)
• crates/transaction/src/v1/transaction.rs (2 hunks)
• crates/wallet/sdk/src/apis/stealth_outputs.rs (3 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/api.rs (13 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/error.rs (1 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/mod.rs (1 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/params.rs (1 hunks)
• crates/wallet/sdk/src/apis/stealth_transfer/types.rs (1 hunks)
• integration_tests/src/wallet_daemon_client.rs (2 hunks)

• crates/transaction/src/v1/instruction.rs
• crates/template_test_tooling/src/read_only_state_store.rs
• bindings/src/types/wallet-daemon-client/StealthTransfer.ts
• bindings/src/types/tari-indexer-client/IndexerGetIdentityResponse.ts
• clients/wallet_daemon_client/src/types.rs
• bindings/src/types/Instruction.ts
• crates/wallet/sdk/src/apis/stealth_transfer/types.rs
• applications/tari_walletd/web_ui/src/services/api/hooks/useAccounts.ts
• integration_tests/src/wallet_daemon_client.rs
• crates/p2p/src/conversions/transaction.rs
• crates/engine/src/runtime/working_state.rs
• crates/wallet/sdk/src/apis/stealth_outputs.rs
• crates/wallet/sdk/src/apis/stealth_transfer/error.rs
• crates/template_lib/src/component/instance.rs
• crates/wallet/sdk/src/apis/stealth_transfer/mod.rs
• clients/javascript/wallet_daemon_client/package.json
• crates/engine/tests/account.rs
• crates/template_test_tooling/templates/faucet/src/lib.rs
• crates/engine/src/runtime/impl.rs

• GitHub Check: test
• GitHub Check: machete
• GitHub Check: check nightly
• GitHub Check: check stable
• GitHub Check: clippy
• GitHub Check: fmt

crates/engine/tests/test.rs (2)

99-99: LGTM! Closure signature updated correctly.

The closure signature has been updated to match the new with_substates API. The first parameter is correctly marked as unused with the underscore prefix.

---

99-110: Based on my verification:

The removal of the nft_indexes module is intentional and complete.

The search found no references to nft_indexes, nft_index, setup_nft_index, or test_new_nft_index anywhere in the codebase.

Test coverage for NFT functionality is actively maintained through:

• mod basic_nft (lines 506-891): Tests core NFT functionality including resource creation, minting, burning, and mutable data updates
• mod emoji_id (lines 893-1025): Tests NFT creation with specific ID formats (emoji-based)
• mod tickets (lines 1026+): Tests NFT use case with state mutations and access control
• Integration tests: Extensive NFT operations (mint, list, get, transfer) in integration_tests/tests/cucumber.rs and wallet daemon handlers

The NFT indexing functionality itself continues to be supported in the runtime, storage, and wallet SDK layers. The removal only affects the dedicated test module, and alternative test coverage is comprehensive.

bindings/src/wallet-daemon-client.ts (1)

35-35: LGTM! StealthTransfer export added to public API.

The export properly exposes the new StealthTransfer type, enabling consumers to use it with the updated StealthTransferRequest that now accepts an array of transfers.

crates/engine/src/runtime/mod.rs (1)

192-192: LGTM! Workspace write capability added to RuntimeInterface.

The new put_on_workspace method properly extends the runtime interface to support writing IndexedValue to a workspace. This is used by the new TakeFromBucket instruction to place the output bucket onto the workspace.

bindings/src/types/wallet-daemon-client/StealthTransferRequest.ts (1)

5-14: LGTM! API refactored to support multiple transfers.

The refactoring successfully enables multiple stealth transfers in a single transaction by:

• Replacing single destination_address with transfers: Array<StealthTransfer>
• Moving per-transfer fields (blinded_output_amount, revealed_output_amount, output_memo) into the StealthTransfer type

This is a clean implementation of the PR's core feature and aligns with the breaking changes notice.

crates/transaction/src/v1/transaction.rs (1)

191-191: LGTM! Weight calculation added for TakeFromBucket.

The weight of 1 is appropriate for the TakeFromBucket instruction, as it performs a simple workspace bucket operation.

crates/p2p/proto/transaction.proto (1)

65-69: LGTM! TakeFromBucket message structure is correct.

The message fields are appropriately typed:

• input_bucket as WorkspaceOffsetId for source bucket reference
• amount as Amount for the quantity to take
• output_bucket as uint32 matching the WorkspaceId type

crates/engine/src/transaction/processor.rs (1)

319-336: All edge cases are properly handled—no changes needed.

The implementation correctly handles all identified scenarios:

• Insufficient balance: ResourceError::InsufficientBalance is returned with descriptive message showing required vs available amounts
• Invalid bucket reference: RuntimeError::InvalidArgument is returned if bucket_id is missing
• Negative/zero amounts: Template-level assert!(amount.is_positive()) validates amounts

All errors propagate correctly through the ? operator chain in the processor.

applications/tari_walletd/src/handlers/accounts.rs (1)

975-984: LGTM! Clean transformation from request to API parameters.

The mapping from transfers array to TransferOutput structs is straightforward and correctly transforms the per-transfer fields. Validation occurs downstream via params.validate(network) at line 987, which ensures all constraints are checked before processing.

crates/wallet/sdk/src/apis/stealth_transfer/params.rs (4)

30-46: LGTM! Validation correctly enforces constraints.

The empty outputs check and blinded output count validation properly address the MAX_LAZY_BP_AGG_FACTORS constraint. Using is_positive() to count blinded outputs is correct since negative amounts are rejected separately and zero-amount outputs don't contribute to bulletproof aggregation.

---

48-88: LGTM! Comprehensive per-output validation.

The validation logic correctly enforces:

• Non-negative amounts for both blinded and revealed components
• At least one positive amount per output (preventing zero-value outputs)
• Network consistency between destination address and wallet
• Address format validity

---

93-119: LGTM! Helper methods are clear and correctly implemented.

The aggregation methods properly sum amounts across outputs, and the TransferOutput struct provides a clean abstraction for per-transfer parameters.

---

121-136: LGTM! Fallible conversion properly handles errors.

The TryFrom implementation correctly addresses the previous review comment by making the conversion fallible and properly propagating address conversion errors. Using only blinded_amount (line 132) is correct, as StealthOutputToCreate represents the confidential portion, with revealed amounts handled separately in the transaction flow.

crates/wallet/sdk/src/apis/stealth_transfer/api.rs (4)

319-328: LGTM! Per-output destination handling is correctly implemented.

The loop properly determines which destination accounts need creation and populates the required substate inputs. Using a HashSet for accounts_to_create correctly deduplicates when multiple outputs target the same new account. The async calls in the loop are acceptable given the validated output count limit.

---

593-680: LGTM! Comprehensive destination account determination logic.

The helper correctly handles all scenarios:

• Early exit for pure blinded transfers (no account needed)
• Local account optimization to avoid network calls
• Proper differentiation between confirmed and unconfirmed local accounts
• Network queries with appropriate error handling
• Vault detection and input population

The logic properly populates substate_inputs and returns accurate account creation flags.

---

497-501: LGTM! Fallible output construction properly propagates errors.

The conversion from TransferOutput to StealthOutputToCreate correctly uses the fallible TryFrom implementation, ensuring address conversion errors are caught and propagated before transaction generation.

---

513-520: LGTM! Transfer statement generation correctly combines outputs and change.

The chaining of outputs_to_create with the optional change_output and filtering for positive amounts ensures only valid outputs are included in the statement.

Cargo.toml (1)

1-3: Verify that template version files were updated per the NOTE requirement.

Line 1 explicitly documents that template version files must be updated when editing the workspace version. Confirm that the version in template_built_in/templates/account and template_built_in/templates/account_nft has also been bumped to 0.14.0 to maintain consistency across the workspace.

Run the following to verify template versions were updated: